home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power CD-ROM!! 8
/
Power CD-ROM 8.iso
/
prgmming
/
oldutil
/
fastbat.txt
< prev
next >
Wrap
Text File
|
1994-12-10
|
4KB
|
109 lines
SPEEDING UP BATCH FILES
Batch files make life a lot easier, but they are very slow. Even when
using batch files in RAM disks, execution time is quite noticeable. It
reminds me of the time when a batch file meant a batch of cards. The
techniques described here reduce the time required to execute batch
file by as much as an order of magnitude.
Execution time is closely related to the number of lines rather than
the number of characters. To save time put as many commands on one
line as possible. Some ways to do this:
1. Instead of using a lot of lines for remarks, put what you have to
say in a file and issue the batch command TYPE FILE. TYPing a file
takes less than 30% as long as echoing the same information from a
batch file.
2. Instead of using a lot of lines to issue commands, put all the
commands in a FOR subcommand. For instance, your autoexec.bat file
might start out
fastdisk
parint
scrnsave
spool 7
sk
c:
Instead, just say
for %%f in (fastdisk parint scrnsave spool:7 sk c:) do %%f
This reduces six lines to one. In Dos 2.1, but not in 3.0, you can
eliminate spaces and slightly decrease execution time like this:
for %%fin(fastdisk parint scrnsave spool:7 sk c:)do%%f
Note the colon between spool and 7. You can't have any spaces within
the parentheses except to denote the beginning of a new command.
3. When copying files use the FOR subcommand and wild cards like this:
for %%fin(print v sp)docopy a:%%f???.*
The FOR subcommand does not support wild cards within the parentheses.
How much time the FOR subcommand will save, if any, depends on how the
disk buffers are used while the subcommand is being executed. DOS
remembers the entire subcommand. It doesn't have to go back to disk to
read more of the subcommand as it goes along. But DOS doesn't remember
the contents of the batch file unless it is held in disk buffers.
Whether or not the disk buffers keep the contents of the batch file
depends on what you're doing between batch commands.
4. The IF subcommand supports conditional commands and the FOR
subcommand.
For instance, you
might want to see if a file exists and, if it does, to run several
programs and then to return to the menu; or, if it doesn't to display a
message and return to the menu.
A batch file for this task might look like this:
If exist myufile goto programs
echo File does not exist. Try again.
d:menu
:programs
myprog.ram
second.prg
third
d:menu
But it will run faster like this:
If exist myfile for %%fin(myprog.ram second.prg third d:menu)do%%f
for %%fin(echo d:menu)do%%f File does not exist. Try again,
5. When a command processor is or another batch file is invoked, batch
processing for the first batch is terminated. You don't need to exit
the batch file. For example, in the batch file fragment below, the
command GOTO GETOUT (and probably the label :GETOUT) is unnecessary and
will increase execution time in some cases:
..
command c:
goto to getout
..
..
:getout.
6. A fast way to get out of the middle of a batch file is to issue a
command for another batch file, say a file called exit. EXIT can contain
only the command REM or just a dot or better yet nothing. A file that
contains nothing doesn't take up any disk space. You can create such a
file with another batch file, say autoexec.bat, by inserting this command
for %%fin(echo rem)do%%f >d:exit.bat
The rem part of the command can be any command that doesn't look for
parameters on the command line, e.g. cls or pause or sk.
7. Of course, running batch files from a RAM disk is a big help. It's
sometimes worth transferring control to a batch file that has been
copied onto your RAM disk. The time required for handling the batch
operations in a RAM disk is less than a third of that required for a
floppy.
8. Putting an end-of-file marker (ASCII 26 or Control Z) on the same
line and immediately after the last command, will prevent annoying
multiple prompts at the end of batch processing.
Bob Unferth Wilmette, IL